游戏服务器架构系列前面分享的文章有：
- 分布式架构 - https://www.jianshu.com/p/84ab097df650
- 网关服务 - https://www.jianshu.com/p/fcf60d64c6c9
- 网关限流 - https://www.jianshu.com/p/0bd8587084ef
- 网关协议加密 - https://www.jianshu.com/p/26b6f417413a
当架构中有了网关之后，客户端就可以连接上来了。接下来客户端就需要请求游戏业务了，网关负责转发；
那么问题来了，网关怎么知道转发到哪里？
一、解决网关转发到“业务服务器”
面对游戏需求，我们的结构如下：
【客户端 * N】 -----请求----> 【网关服务器 * N】 -----请求----> 【业务服务器 * 1】
从上图，我们可以看到有N台客户端请求N台网关服务器，然后转发到1台业务服务器；
按照这种结构，先用最快速的方法，把功能实现了：
把业务服务器的“IP”和“端口”写死在网关服务器代码里。
过了两天...
策划说：我们现在需要增加一台战斗服务器，没有战斗的游戏怎么玩？
二、解决网关转发到<多台>业务服务器
当网关服务器后面有多台业务服务器时，我们发现写死在代码里，总不是那么好，修改特别不方便。
为了避免后续又增加很多业务服务器，我们决定：
用JSON或XML结构把每一台业务服务器的“IP”和“端口”写死在配置（文件或数据库）中。
当增加、修改、删除业务服务器时，直接修改配置文件就搞定了，比写死在代码里好多了。
终于上线了...
运营说：今天怎么线上突然报了很多“战斗请求失败”的问题啊？
先让我追查一番...
终于发现，原来是有1个战斗服务器因为“内存满了”挂掉了，当网关在按照配置文件请求时，每次请求到这个战斗服务器就出现“战斗请求失败”了。
这下该怎么办呢？
话不多说，先修复掉...
过了几天，运营又打电话来，说又挂了...，表示很无奈！！！
三、解决业务服务器突然挂掉的问题？
业务服务器挂掉是经常发生的事情，有时候“内存满了”，“磁盘满了”，还有的时候就是代码BUG了。
那么，业务服务器挂了怎么办？我觉得网关应该直接转到其他业务服务器，而不能转到这个挂掉的业务服务器。
如果当前业务服务器不够了，我能动态添加业务服务器去做支援。所以，我们就需要做到：
服务注册：当业务服务器启动后，自动注册到配置中心；用于增加服务后，能够立即被调用；
服务发现：客户端可以从配置中心获取到所有的业务服务器信息；
健康检查：当业务服务器挂掉或无法处理请求时，需要被及时发现，然后从配置中心移除；
负载均衡：当某个业务的服务有多个时，可提供负载均衡算法进行选择；
看到上面这几个需求，你是不是怕了，有没有种感觉“项目又要延期了”？
不要怕，我给你推荐几个工具！
- Etcd：一个高可用，分布式，一致的key-value存储，用来共享配置和服务发现。Kubernetes和Cloudfoundry都使用了etcd；
- Consul：一个发现和配置服务的工具。客户端可以利用它提供的API，注册和发现服务。Consul可以执行监控检测来实现服务的高可用；
- Apache Zookeeper：一个常用的，为分布式应用设计的高可用协调服务，最开始Zookeeper是Hadoop的子项目，现在已经顶级项目了。
- Eureka：Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。
这些工具都可以解决服务注册与发现，流程如下：
这几个工具的对比如下：
四、工具理论 - 服务发现模式（Service Discovery）
服务发现模式分：客户端服务发现（client-side discovery）和服务器端服务发现（server-side discovery）
客户端服务发现（client-side discovery）
- 客户端请求服务注册表，获取一个服务列表；
- 客户端使用一个负载均衡算法，选择一个服务；
- 客户端直接请求这个服务。
优点：简单直接；客户端实现负载均衡。
缺点：每一种客户端都要实现一套服务发现逻辑；无法根据服务器使用情况进行负载均衡；
服务器端服务发现（server-side discovery）
- 客户端请求服务端的负载均衡器（如网关）；
- 负载均衡器去请求服务注册表，利用负载算法选择一个服务；
- 获取具体服务后，可直接转发，也可发给客户端进行调用。
优点：客户端不需要知道具体的负载算法，不需要实现服务发现逻辑；
缺点：对于负载均衡器的稳定性要求比较高（如果是网关，就要开多台），也增加了整体系统的维护性。
五、工具理论 - 服务注册表（Service Registry）
服务注册表是服务发现的关键部分，是一个包含了服务实例的网络地址的数据库，必须是高可用和最新的。客户端可以缓存从服务注册表处获得的网络地址。但是，这些信息最终会失效，客户端会找不到服务实例。所以，服务注册表由一个服务器集群组成，通过应用协议来保持一致性。
六、工具理论 - 服务注册（Service Registration）
服务注册模式分：服务实例自己注册（self-registration模式）和其它的系统组件管理服务实例的注册（third-party registration模式
自注册模式（The Self-Registration Pattern）
- 服务实例启动后，自己注册到服务注册表
- 服务实例停止后，自动从服务注册表注销
- 当服务实例异常挂掉时，服务注册表通过“过期时间”或“心跳检测”来判断失效
优点：简单，不需要其他组件
缺点：每一种服务实例需要实现注册和注销的代码
第三方注册模式（The Third-Party Registration Pattern）
- 服务实例启动后，由另一个系统组件service registrar负责检测和注册
- 服务实例停止（或异常挂掉）后，也同上
优点：解耦了服务实例和服务注册表，不需要实现服务注册代码；
缺点：对系统组件service registrar的稳定性要求很高，也增加了整个系统的维护性。
